为什么要基于 PixeLAW 开发游戏？
加密原生游戏
“加密原生游戏是一种最大限度地拥抱区块链开发模式和区块链精神的游戏”。
新技术是用来做全新的事情、探索全新的可能性，而非更好地、渐进地做旧的事情。当我们谈“全链游戏”的时候，实际上是在强调一种“敢为天下先”的探索精神，利用区块链的特有属性，创造全新的产品体验，而不仅仅是教条式的将游戏逻辑、游戏数据全部放在区块链上。以此来看，全链游戏引擎（如：MUD、Dojo、Keystone、Paima Engine、World Engine 等）是符合这种精神的，因为它们创造了区块链游戏引擎（或者叫区块链应用开发框架），这是之前从未有过的。
反观全链游戏领域，虽然游戏数量众多，但真正有原生创新的不算太多。当然这跟游戏机制（game mechanics）的有限性有很大关系，游戏领域已经充分探索了所有可能的游戏机制，要再创造新的游戏模式非常困难。
但在游戏模式之上，依然有可探索的空间。像 PixeLAW 这样的项目，从区块链的“可互操作性”出发，探索游戏间互操作性这一全新领域。暂时不能断定 PixeLAW 是最正确的方向，但至少离正确的方向更近了一步，这是我们基于 PixeLAW 开发游戏的主要原因。
图片来源：https://pixelaw.github.io/book/
关于 PixeLAW 的产品形态、设计哲学在《PixeLAW：构建全链游戏的最简单⽅法》和《PixeLAW 的工程美学》中有详细介绍。接下来将主要介绍我们基于 PixeLAW 开发全链版 2048 过程中，对 PixeLAW 的微观体感和由此引发的一些思考。
使用 PixeLAW 的微观体感
对第一次接触 Cairo 语言的开发者来说，基于 PixeLAW 开发游戏并不容易，需要同时熟悉 Starknet 区块链、Dojo 框架、Cairo 语言和 PixeLAW。此外，Cairo 编程语言的设计哲学、语言成熟度、工具链丰富度等方面，较 Solidity（以太坊智能合约编程语言） 也有很大不同，对开发者还是有相当大的挑战的，接下来将一一介绍。
Starknet
Starknet 是采用 ZK Rollup 的以太坊 Layer 2 区块链，也被称为“最适合全链游戏的 Layer 2”。我认为这个说法包含多个维度，技术维度，Starknet 有链原生的零知识证明机制（OP Stack 似乎也可以在其 Stack 中插入一层 ZKP 来达到类似效果）；生态维度，Starknet 基金会、Bibliotheca DAO 等机构组织的 Grant 和 Game jam 等活动；当然也有营销的成分，毕竟 Starknet 生态需要与其他 ZK Rollup 区块链甚至 OP Rollup 区块链生态竞争来赢得更多开发者。
Dojo 框架
Dojo 框架可以粗略理解为 MUD 框架（首个全链应用开发框架）的 Cairo 语言实现，目前针对 Starknet 生态。如果你对 MUD 框架有一定了解，当看到 Dojo 框架时，除编程语言的差异，其他方面会感到很熟悉。此外，Dojo 配备了与之搭配使用的工具链（包含：Katana、Sozo、Torii、Slot 等），从这个意义上说，叫“Dojo 工具集”更合适。
Cairo 语言
Cairo 语言由 StarkWare 团队于 2020 年开始开发，是为通用计算生成 STARK 证明的图灵完备编程语言，使 Starknet 作为 Layer 2 能够进行可证明性计算。可证明性意味着可以在 Starknet 上生成证明，并在以太坊网络（Layer 1）上验证程序的输出已经被正确计算。由于计算发生在 Layer 2，而 Layer 1 使用较少的计算资源即可验证生成的证明（验证过程不需要重新执行计算），从而实现更好的计算性能和数据安全性。
从 Solidity 开发者的角度来说，由于 Cairo 语言在安全性和计算性能方面的取舍，加之 Cairo 语言本身尚处早期，学习门槛较 Solidity 高、语言特性不如 Solidity 丰富，完成同样的功能，使用 Cairo 语言开发工作量有可能会更大。
四种智能合约语言对比。图片来源：https://medium.com/scb10x/smart-contract-programming-languages-trade-offs-e2797f0b2968
PixeLAW
PixeLAW 于 2023 年7月在巴黎 ETHGlobal 黑客松期间诞生，并获得 Starknet Best Use 奖项。开发体验方面，除 Cairo 语言的学习门槛外，总体还是很不错的。PixeLAW Book 读起来很流畅，对于想在本地部署 PixeLAW Core、PixeLAW app_template 的开发者来说，整个过程相当丝滑。不过想要基于 PixeLAW 开发游戏的话，可能需要进一步阅读 PixeLAW examples 的源代码以获得更多工程实现上的灵感。
开发 BRC2048 的体验
沟通流畅
我们基于 PixeLAW 开发全链版 2048 （BRC2048）的过程中，虽然遇到有些特性尚未被支持，也遇到过 PixeLAW 的一些小 bug，但总体上 PixeLAW 提供的功能足以开发我们的游戏。此外，特别值得一提的是，与 PixeLAW 团队沟通总是很顺畅，PixeLAW 团队的回复总是很及时，要知道在跨时区协作的场景下，做到这一点并不容易。这里要特别感谢 PixeLAW 团队的@jk、@syora、@thiscaspar 、@mariz-ov，以及 MetaCat 团队的 @ilhte 。
工作量更少
之前我们基于 MUD 框架开发过 2048，在基于 PixeLAW 开发 2048 的过程中，明显感觉工作量少了。只需专注智能合约开发，即可完成游戏开发。这是非常神奇的体验，也是全新的开发范式！这很大程度上归功于 PixeLAW 的理念：用最小的组件开始一个世界，并让它与社区一起成长。从一个像素块和最少的规则开始，然后在此基础上添加新规则、新游戏等，并逐步让游戏之间有互操作性。
少即是多
下图是我们基于 PixeLAW 开发的 2048 游戏（也是 PixeLAW 的主界面）。由于组成游戏的最小单元是单个像素块，因此游戏画面呈现上会有所局限，进而导致并非所有游戏类型都适合用 PixeLAW 开发。但对于想要深入探索游戏间互操作性的团队来说，PixeLAW 是很好的试验场。单个像素块是最小的可编程单元、也是最小的互操作性单元，关注核心目标，忽略次要事务，不失为一种明智之举。
BRC2048 游戏界面
写在最后
BRC2048 目前只完成了初步的游戏构建，接下来会进一步完善游戏功能，并与 PixeLAW 团队一起，探索游戏间（比如：贪吃蛇、画图游戏）互操作性的具体实现路径，以及 PixeLAW 在自主世界领域的更多可能性。
让我们以 cellula.live 创始人 Eric 的一句话来结尾：当前处于全链游戏/自主世界的极早期，个体只有追求极致的差异化，才能获得整个赛道的生存机率最大化。